Cryptographic devices include, by way of example, one-time passcode (OTP) devices such as hardware authentication tokens. Authentication tokens are typically implemented as small, hand-held devices that display a series of passcodes over time. A user equipped with such an authentication token reads the currently displayed passcode and enters it into a computer or other element of an authentication system as part of an authentication operation. This type of dynamic passcode arrangement offers a significant security improvement over authentication based on a static password.
Conventional authentication tokens include both time-synchronous and event-synchronous tokens.
In a typical time-synchronous token, the displayed passcodes are based on a secret value and the time of day. A verifier with access to the secret value and a time of day clock can verify that a given presented passcode is valid.
One particular example of a time-synchronous authentication token is the RSA SecurID® user authentication token, commercially available from RSA, The Security Division of EMC Corporation, of Bedford, Mass., U.S.A.
Event-synchronous tokens generate passcodes in response to a designated event, such as a user pressing a button on the token. Each time the button is pressed, a new passcode is generated based on a secret value and an event counter. A verifier with access to the secret value and the current event count can verify that a given presented passcode is valid.
Other known types of authentication tokens include hybrid time-synchronous and event-synchronous tokens.
Passcodes can be communicated directly from the authentication token to a computer or other element of an authentication system, instead of being displayed to the user. For example, a wired connection such as a universal serial bus (USB) interface may be used for this purpose. Wireless authentication tokens are also known. In such tokens, the passcodes are wirelessly communicated to a computer or other element of an authentication system. These wired or wireless arrangements, also referred to herein as connected tokens, save the user the trouble of reading the passcode from the display and manually entering it into the computer.
Additional details of exemplary conventional authentication tokens can be found in, for example, U.S. Pat. No. 4,720,860, entitled “Method and Apparatus for Positively Identifying an Individual,” U.S. Pat. No. 5,168,520, entitled “Method and Apparatus for Personal Identification,” and U.S. Pat. No. 5,361,062, entitled “Personal Security System,” all of which are incorporated by reference herein.
Many authentication systems are configured to require that a user enter a personal identification number (PIN) or other static access code in addition to entering the passcode from the authentication token. This provides an additional security factor, based on something the user knows, thereby protecting against unauthorized use of an authentication token that is lost or stolen. Such an arrangement is generally referred to as two-factor authentication, in that authentication is based on something the user has (e.g., the authentication token) as well as something the user knows (e.g., the PIN).
Authentication tokens and other OTP devices are typically programmed with a random seed or other type of key that is also stored in a token record file. The record file is loaded into an authentication server, such that the server can create matching passcodes for the authentication token based on the key and the current time or current event count. When the user first activates the token, the server stores the user PIN in association with the key corresponding to that token.
An adversary possessing a stolen record file is able to generate correct passcodes for each token key stored in that file. In order to impersonate a particular user, the adversary would generally have to “phish” or otherwise obtain access to the details of at least one user login session such that it learns the user PIN as well as one passcode that can be matched to one of the token keys in the record file.
Security issues such as these can be addressed through the use of unidirectional or broadcast key updates. In this manner, the key associated with a particular authentication token is periodically refreshed or otherwise updated.
However, even in strongly-defended systems, intrusions are becoming inevitable due to the increasing sophistication of advanced persistent threats (APTs). APTs are usually mounted by well-funded attackers with very specific targets. To accomplish their goals, attackers orchestrating an APT typically introduce periods of delay among different stages of the attack, advance slowly while keeping their footprint low, and control the propagation of the attack through the use of human operators. Due to these and other threats, the approach of trying to build impenetrable systems is proving unworkable. Instead, secure systems need to be architected in an intrusion-resilient way.
Proactive cryptography can be used to create resilience against continuous adversarial compromise. In one type of proactive system, shares of a secret key sk are distributed among multiple servers. These servers collaboratively refresh their shares on a periodic basis, that is, they randomly redistribute sk. Thus, while sk itself remains invariant, servers can “heal” after compromise, in the sense that a key share exposed to an adversary is ultimately invalidated by a refresh operation. The refresh operations are performed at the start of respective time periods. Such time periods are examples of what more generally referred to herein as “epochs.” Epochs in conventional proactive authentication systems are typically fixed-length intervals.
Additional details regarding conventional proactive systems of the type described above can be found in, for example, R. Ostrovsky and M. Yung, “How to withstand mobile virus attacks,” Proceedings of the 10th annual ACM symposium on Principles of Distributed Computing, PODC '91, pp. 51-59, New York, N.Y., USA, 1991, and R. Canetti, R. Gennaro and A. Herzberg, “Proactive security: Long-term protection against break-ins,” CryptoBytes, Vol. 3, pp. 1-8, 1997, which are incorporated by reference herein.
Another type of proactive system is an intrusion-resistant distributed pseudorandom number generation system. In a system of this type, a set of servers holds a pseudorandom value that is updated at the beginning of every epoch. A corresponding authentication token can locally generate the value in a given period to authenticate to the servers. See R. Canetti and A. Herzberg, “Maintaining security in the presence of transient faults,” CRYPTO, pp. 425-438, 1994, which is incorporated by reference herein.
Proactive cryptography generally aims to provide protection even in cases where a breach goes undetected. However, a proactive system may be configured to accelerate the refresh process upon the detection of a breach. See, for example, S. Xu, M. Yung, and L. Chen, “SocialClouds: Concept, Security Architecture and Some Mechanisms,” Vol. 6163, pp. 104-128, Springer Berlin/Heidelberg, 2010, which is incorporated by reference herein. One drawback of an arrangement of this type is that it is generally not appropriate for use with hardware authentication tokens or other similar cryptographic devices, such as software authentication tokens implemented in a mobile telephone.